Bug Proofing Visual Basic: A Guide to Error Handling and Prevention
(Publisher: John Wiley & Sons, Inc.)
Author(s): Rod Stephens
ISBN: 0471323519
Publication Date: 11/01/98

Write Test Routines

When you test a routine, write test code that you can save for later use. Give test routines appropriate names and place them in test modules. For example, to test a subroutine named FillExpenseTable, write a subroutine named Test_FillExpenseTable. If FillExpenseTable is contained in the module Expenses, put subroutine Test_FillExpenseTable in a module named Test_Expenses.

If the test routine needs access to variables local to the Expenses module, put it in that module. Then use conditional compilation symbols to make it easy to remove the test routine before you compile the final project. Unfortunately, this can be a bit awkward in Visual Basic. If you place an #If statement before a routine and an #End If statement after it, the code editor may not display those statements together with the routine. It may display the #End If statement at the top of the following subroutine. There are two ways you can handle this. First, you can block out only the inside of the routine and leave its declaration and End statement in the file.

Alternatively, you can set the editor to full module view. Select the Tools menu’s Options command. Click on the Editor tab and select the Full Module View (in Visual Basic 4) or Default to Full Module View (in Visual Basic 5 and 6) checkbox. This will let you see the #If Then and #End If statements at the same time as the routine they surround.

Save all of your test routines for later use. When you modify the original routine, you will need to retest it to make sure nothing has broken. If you keep the test routines, retesting the modified code will be easy. Remove the test modules from the project before you build the final system, but keep those modules around somewhere.

Create a special Test menu in the application’s main menu. Put commands in this menu to run the test routines. Before compiling the program’s final version, set this menu’s Visible property to False so it is hidden from users.

Look for Bugs

It may seem silly to say this, but the purpose of testing is to find bugs, not to merely pass a test. If passing a test were the goal, you could write tests that did nothing and every routine would pass.

To be useful, a test must find bugs. Every time you find and eliminate a bug, you improve the code. If you do not find any bugs, the test is not helping. You should think of the test as a failure because it failed to improve the code.

Design tests to find bugs. Exercise the toughest special cases you can imagine. Try to flush the bugs out rather than avoiding them.

Test When You Are Alert

When you are inattentive, you are more likely to overlook bugs that you should be able to catch during testing. You will not question suspicious results as closely. You may invent reasons for odd behavior without proving you are correct. You may not think about all of the possible special cases and follow all of the paths through the code.

Test when you are alert. Take a short break between coding and testing. If your attention wanes, take another break. Stay sharp and catch as many bugs as you can while it is still relatively easy. If you miss them now because you are not paying attention, you will need to find them later.

Test a little bit at a time. Testing for too many continuous hours can make you lose your focus. If you have trouble concentrating on the task at hand, take a break, stretch, walk around, and clear your mind. Then come back refreshed and ready to concentrate.

Test It Anyway

If the code is too simple to be wrong, test it anyway. If you make only a tiny change that cannot possibly change the routine’s results, test it anyway. If the code looks perfect, test it anyway. Even if you only change comments, test it anyway. It is very easy to intend to change comments and then make just one inconsequential change to the code at the same time. It is surprising how often a change that cannot possibly hurt the code causes a bug. Test to make sure.

Test any time you make changes to the code. Modifying code is much more likely to introduce bugs than writing new code is. Whenever you make a change, no matter how trivial, there is a reasonable chance that you have introduced a new bug. Test the code immediately to catch the bug now.

Running a test that finds no bugs may not be interesting, but it is better than searching for bugs later in code you thought was safe.

Test Ported Code

Test code when you port it from one platform or version of Visual Basic to another. Usually, the code will work, but occasionally, subtle differences will make working code fail.

For example, both Windows 95 and Windows NT declare 32-bit API functions using long integers. The device context handle (hDC) required by many API functions is declared as a long integer. However, Windows 95 uses numbers for hDCs that are less than 32,768. The program can get away with saving hDC values in normal 2-byte integers. If you move this code to Windows NT, it will crash. Windows NT uses hDC values that are too big to fit in 2-byte integers. When the code tries to assign a big long integer value into a short integer, it generates an overflow error.

Test code when you port it. If you have followed the advice of the previous sections, you have saved the test routines you used to test the original code. In that case, testing the code will be easy.

Start from the Immediate Window

Instead of running the entire program, you can test a single subroutine from within the Immediate window. First, set a breakpoint at the beginning of the subroutine. Set another at the beginning of the program and press F5. The program will start and then stop almost immediately.

Now in the Immediate window, enter the name of the subroutine together with any parameters it needs. If the routine modifies any of its parameters, you must create temporary test variables in the main program so you will have variables to pass to the routine. Then press the carriage return key. Visual Basic will invoke the subroutine and stop at your breakpoint.

Executing a function from the Immediate window is generally similar. Type a question mark followed by the function’s name, including any arguments it needs. Press the carriage return key to make Visual Basic execute the function and display its return value.

Examine Variables

As you step through a routine, you can easily view the routine’s variables. In Visual Basic 4, click on the variable in the source code window. Then click the Instant Watch button or press Shift-F9. In Visual Basic 5 and 6, you can also let the mouse float over the variable to see its value.

You can make the Immediate window display the variable’s value by typing a question mark, followed by the variable’s name, followed by a carriage return. For example, the following command makes the Immediate window display the value of the variable X.

Figure 14.1  Adding a watch for a variable.

You can make the code itself print values to the Immediate window using the Debug.Print statement. For instance, the following code makes the program display the string “X” followed by the value of variable X.

Debug.Print “X” & Str$(X)

If you want to view the value of a variable frequently, you can set a watch on it. In Visual Basic 4, click on the variable’s name and select the Tools menu’s Add Watch command. In Visual Basic 5 and 6, click on the variable and select the Debug menu’s Add Watch command. You will then see the dialog shown in Figure 14.1. Click the OK button to add the watch.